<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>评论-马丁福勒的网站-敏捷软件开发</title>

    <link rel="stylesheet" href="./architecture.css">
</head>
<!-- 这个是首页 -->

<body>

    <!-- 页面头部 -->
    <header id="banner"
        style="background-image: url('./img/poetta.png'); background-repeat: no-repeat">
        <div class="name-logo">
            <a href="https://martinfowler.com">
                <img src="./mf-name-white.png">
            </a>
        </div>
        <div class="searach">
            <form method="GET" action="https://www.google.com/search">
                <input type="hidden" name="ie" value="UTF-8">
                <input type="hidden" name="oe" value="UTF-8">
                <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                <button class="button" type="submit" name="btnG" value=" " title="Search">
                    <input type="hidden" name="domains" value="martinfowler.com">
                    <input type="hidden" name="sitesearch" value="">
                    <input type="hidden" name="sitesearch" value="martinfowler.com">
                </button>
            </form>
        </div>
        <div class="menu-button navmenu-button">
            <a class="icon icon-bars" href="#navmenu-bottom"></a>
        </div>
        <nav class="top-menu">
            <ul>
                <li><a class="" href="https://refactoring.com">
                        <!-- Refactoring --> 重构
                    </a></li>

                <li><a class="" href="./agile.html">
                        <!-- Agile --> 敏捷
                    </a></li>

                <li><a class="" href="./architecture">
                        <!-- Architecture --> 架构
                    </a></li>

                <li><a class="" href="./aboutMe.html">
                        <!-- About --> 关于martinfowler
                    </a></li>

                <li><a class="tw" href="https://www.thoughtworks.com">ThoughtWorks</a></li>

                <li><a class="icon icon-rss" href="./feed.atom" title="feed"></a></li>

                <li><a class="icon icon-twitter" href="https://www.twitter.com/martinfowler" title="twitter stream"></a>
                </li>
            </ul>
        </nav>
    </header>

    <nav id="top-navmenu" style="display: none;">
        <nav class="navmenu">
            <div class="nav-head">
                <div class="search">
                    <!-- SiteSearch Google -->
                    <form method="GET" action="https://www.google.com/search">
                        <input type="hidden" name="ie" value="UTF-8">
                        <input type="hidden" name="oe" value="UTF-8">
                        <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                        <button class="button" type="submit" name="btnG" value=" " title="Search">
                            <input type="hidden" name="domains" value="martinfowler.com">
                            <input type="hidden" name="sitesearch" value="">
                            <input type="hidden" name="sitesearch" value="martinfowler.com">

                        </button>
                    </form>
                </div>

                <div class="closediv">
                    <span class="close" title="close"></span>
                </div>
            </div>

            <div class="nav-body">
                <div class="topics">
                    <h2>Topics</h2>

                    <p><a href="./architecture">
                            <!-- Architecture --> 架构
                        </a></p>

                    <p><a href="https://refactoring.com">
                            <!-- Refactoring --> 重构
                        </a></p>

                    <p><a href="./agile.html">
                            <!-- Agile --> 敏捷
                        </a></p>

                    <p><a href="./delivery.html">
                            <!-- Delivery --> 交付
                        </a></p>

                    <p><a href="./microservices">
                            <!-- Microservices --> 微服务
                        </a></p>

                    <p><a href="./data">
                            <!-- Data --> 数据
                        </a></p>

                    <p><a href="./testing">
                            <!-- Testing --> 测试
                        </a></p>

                    <p><a href="./dsl.html">
                            <!-- DSL --> 领域特定语言
                        </a></p>
                </div>

                <div class="about">
                    <h2>about me</h2>

                    <p><a href="./aboutMe.html">About</a></p>

                    <p><a href="./books">Books</a></p>

                    <p><a href="./faq.html">FAQ</a></p>
                </div>

                <div class="content">
                    <h2>content</h2>

                    <p><a href="./videos.html">Videos</a></p>

                    <p><a href="./tags">Content Index</a></p>

                    <p><a href="./articles/eurogames">Board Games</a></p>

                    <p><a href="./photos">Photography</a></p>
                </div>

                <div class="tw">
                    <h2>ThoughtWorks</h2>

                    <p><a href="https://thoughtworks.com/insights">Insights</a></p>

                    <p><a href="https://thoughtworks.com/careers">Careers</a></p>

                    <p><a href="https://thoughtworks.com/products">Products</a></p>
                </div>

                <div class="feeds">
                    <h2>follow</h2>

                    <p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

                    <p><a href="./feed.atom">RSS</a></p>
                </div>
            </div>
        </nav>
    </nav>

    <!-- 网页主体 -->
    <main>
        <!-- <h1>Software Architecture Guide</h1> -->
        <h1>软件架构指南</h1>

        <section class="lede">
            <section class="main">
                <p>When people in the software industry talk about “architecture”, they refer to a
                    hazily defined notion of the most important aspects of the internal design of a
                    software system. A good architecture is important, otherwise it becomes slower and
                    more expensive to add new capabilities in the future.</p>

                <p>软件从业者谈论 "架构"时, 总是模糊的概念表示软件系统的内部设计的最重要的方面. 
                    良好的架构很重要, 否则系统将来变更需要花费很大代价.</p>

                <p>Like many in the software world, I’ve long been wary of the term “architecture” as
                    it often suggests a separation from programming and an unhealthy dose of pomposity.
                    But I resolve my concern by emphasizing that good architecture is something that
                    supports its own evolution, and is deeply intertwined with programming. Most of my
                    career has revolved about the questions of what good architecture looks like, how
                    teams can create it, and how best to cultivate architectural thinking in our
                    development organizations. This page outlines my view of software
                    architecture and points you to more material about architecture on this site.</p>
                    
                <p>和软件界中的许多人一样，我一直对“架构”这个词持谨慎态度，因为它通常意味着与编程的分离，以及一种不必要的傲慢态度。
                    但是，现在我解决了这个担忧，是通过强调良好的架构是能支持其自身演进的事物，并且结构与编程是深度交织在一起的。
                    我的大部分职业生涯围绕着这样一个问题展开：好的架构看起来是什么样的，团队如何创建它，以及如何在我们的开发组织中最好地培养架构思维。
                    这一页概述了我对软件架构的看法，并指引您在该网站上找到更多关于架构的材料。
                    </p>
            </section>

            <section class="side">
                <p class="guide-explain">A guide to material on martinfowler.com about
                    software architecture.</p>
                    
                <p class="guide-explain">在 martinfowler.com 内关于软件架构的资料指南，</p>

                <div class="author"><a href="./"><img alt="Photo of Martin Fowler" src="./mf.jpg" width="80"></a>
                    <address class="name"><a href="./" rel="author">Martin Fowler</a></address>
                </div>

                <p class="date">
                    <time datetime="2019-08-01">1 Aug 2019</time>
                </p>
            </section>
        </section>

        <section class="row what-why">
            <section class="what" id="WhatIsArchitecture">
                <h2>What is architecture? 什么是架构？</h2>

                <p>People in the software world have long argued about a definition of
                    architecture. For some it's something like the fundamental organization of
                    a system, or the way the highest level components are wired together. My
                    thinking on this was shaped by <a href="./ieeeSoftware/whoNeedsArchitect.pdf">an email exchange
                        with Ralph Johnson</a>, who questioned this phrasing, arguing that
                    there was no objective way to define what was fundamental, or high level
                    and that a better view of architecture was <b>the shared understanding that
                        the expert developers have of the system design.</b></p>

                <p>软件界关于架构定义的争论持续很久了。
                    对于一些人 它是系统根本的组织，或者最高层级组件的连接方式。
                    我的想法受到了<a href="./ieeeSoftware/whoNeedsArchitect.md">与Ralph Johnson通过电子邮件交流</a>的影响，
                    他质疑了这种措辞，认为没有客观的方法来定义什么是根本的，或者什么是高层的，
                    并认为对架构的更好看法是<b>专家开发者对系统设计的一致理解。</b></p>


                <section class="picture ralph-photo">
                    <p class="img-link"><img src="ralph.png">
                    </p>
                    <p class="caption">
                        Ralph Johnson, speaking at QCon
                    </p>
                    <p></p>
                </section>

                <p>A second common style of definition for architecture is that it's “the design
                    decisions that need to be made early in a project”, but Ralph complained about this
                    too, saying that it was more like <b>the decisions you wish you could get right early
                        in a project</b>.</p>
                
                <p>架构的第二个常见定义风格是，它是“需要在项目早期做出的设计决策”。
                    但是Ralph也对这个表示了不满，说这更像是<b>你希望在项目早期就做了的正确决策。</b></p>
                <p>笔记: 这些决策在项目后期才发现都没做，所以是希望，带有悔不当初的意思</p>

                <p>His conclusion was that <b>“Architecture is about the important stuff. Whatever that
                        is”</b>. On first blush, that sounds trite, but I find it carries a lot of richness. It
                    means that the heart of thinking architecturally about software is to decide what is
                    important, (i.e. what is architectural), and then expend energy on keeping those
                    architectural elements in good condition. For a developer to become an architect,
                    they need to be able to recognize what elements are important, recognizing what
                    elements are likely to result in serious problems should they not be controlled.
                </p>
                
                <p>他的结论是：<b>“架构是关于重要的事情。无论那是什么。”</b>. 
                    乍一听，这听起来可能有些陈词滥调，但我发现它蕴含了很多深刻的含义。
                    这意味着从软件架构的角度进行思考的核心是决定什么是重要的（即什么是架构性的），然后投入精力保持这些架构元素的良好状态。
                    对于开发者想要成为架构师，他们需要能够识别哪些元素是重要的，认识到哪些元素如果不加以控制，可能会导致严重的问题。
                </p>
                <p>笔记: 认知到做哪些事可以避免严重问题</p>
                
                <section class="picture what-pdf">
                    <p class="img-link"><a href="./ieeeSoftware/whoNeedsArchitect.pdf"><img src="ieee-arch.png"></a>
                    </p>
                    <p class="caption">
                        Ralph's email formed the core of <a href="./ieeeSoftware/whoNeedsArchitect.pdf">my column for
                            IEEE software</a>, which discussed the meaning of software
                        architecture and the role of an architect.
                    </p>
                    <p class="caption">
                        Ralph 的邮件形成了核心<a href="./ieeeSoftware/whoNeedsArchitect.md">我的专栏 IEEE software</a>, 
                        探讨了软件架构的意义和架构师的角色.
                    </p>
                </section>
            </section>

            <section class="why" id="WhyDoesArchitectureMatter">
                <h2>Why does architecture matter? 为什么架构很重要？</h2>

                <p>Architecture is a tricky subject for the customers and users of
                    software products - as it isn't something they immediately perceive. But a
                    poor architecture is a major contributor to the growth of cruft - elements
                    of the software that impede the ability of developers to understand the
                    software. Software that contains a lot of cruft <a href="./articles/is-quality-worth-cost.html">is
                        much harder to modif</a>y, leading to features
                    that arrive more slowly and with more defects.</p>
                    
                <p>对于软件产品的客户和用户来说，架构是一个棘手的话题，因为这不是他们立刻就能感知到的东西。
                    但是，糟糕的架构是软件中屎山增长的主要原因 —— 软件中那些屎元素，它阻碍开发者理解软件。
                    包含大量屎山代码的软件<a href="./articles/is-quality-worth-cost.html">很难修改</a>，
                    导致新功能推出的速度更慢，缺陷更多。</p>

                <section class="picture why-illus">
                    <p class="img-link"><a href="./articles/is-quality-worth-cost.html"><img
                                src="./articles/is-quality-worth-cost/card.png"></a>
                    </p>
                    <p class="caption"></p>
                    <p></p>
                </section>

                <p>This situation is counter to our usual experience. We are used to
                    something that is "high quality" as something that costs more. For some
                    aspects of software, such as the user-experience, this can be true. But
                    when it comes to the architecture, and other aspects of internal quality,
                    this relationship is reversed. <b>High internal quality leads to faster
                        delivery of new features</b>, because there is less cruft to get in the
                    way.</p>
                
                <p>这种情况与我们通常的体验相反。
                    我们习惯于认为“高质量”的东西成本更高。
                    对于软件的一些方面，例如用户体验，这可能是真的。
                    但是当涉及到架构和其他内在质量方面，这种关系是相反的。
                    <b>高内部质量导致新功能更快推出</b>，因为这样垃圾代码就会少一些，不会造成阻碍。</p>
                
                <p>笔记: 内在质量高导致交付快, 因为 屎山代码少 所以 屎山代码造成的阻碍少</p>

                <p>While it is true that we can sacrifice quality for faster delivery in
                    the short term, before the build up of cruft has an impact, people
                    underestimate how quickly the cruft leads to an overall slower delivery.
                    While this isn't something that can be objectively measured, experienced
                    developers reckon that <b>attention to internal quality pays off in weeks not
                        months.</b></p>

                <p>虽然我们确实可以在短期内为了更快地交付而牺牲质量，
                    但是在垃圾代码的积累造成影响之前，人们总是低估了垃圾代码的迅速，迅速导致整体交付速度变慢。
                    虽然这不是一件可以客观衡量的事情，但经验丰富的开发者认为，<b>对内部质量的关注在几周内就会得到回报，而不是几个月。</b></p>

                <p>笔记: 对垃圾代码存在盲目乐观, 以为现在不会造成危害, 其实危害会迅速出现</p>
                
                <section class="picture">
                    <p class="img-link"><a href="./articles/is-quality-worth-cost.html"><img
                                src="./articles/is-quality-worth-cost/both.png"></a>
                    </p>
                    <p class="caption"></p>
                    <p></p>
                </section>

                <p class="more"><a href="./articles/is-quality-worth-cost.html">Read more…</a></p>
            </section>
        </section>

        <section class="oscon">
            <section class="content">
                <section class="picture">
                    <p class="img-link"><a href="./videos.html#2015-oscon"><img src="oscon.png"></a>
                    </p>
                    <p class="caption"></p>
                    <p></p>
                </section>

                <p>At OSCON in 2015 I gave a <a href="./videos.html#2015-oscon">brief talk</a> (14
                    min) on what architecture is and why it matters.</p>
            </section>
        </section>

        <hr class="sep">

        <section class="synopsis app" id="ApplicationArchitecture">
            <h2>Application Architecture 应用架构</h2>

            <p>The important decisions in software development vary with the scale of
                the context that we're thinking about. A common scale is that of an
                application, hence "application architecture".</p>
                
                
            <p>在软件开发中，什么是重要的决策随着我们思考的上下文规模的不同而变化。
                一个常见的规模是应用程序的规模，因此有“应用程序架构”。</p>
                

            <p>The first problem with defining application architecture is that
                there's no clear definition of what an application is. My view is that
                <a href="./bliki/ApplicationBoundary.html">applications are a social
                    construction</a>:
            </p>
            
            
            <p>定义应用程序架构的第一个问题是，应用程序的定义并不清晰。
                我的观点是
                <a href="./bliki/ApplicationBoundary.html">应用程序是一个社会构成</a>:
            </p>
            <p>笔记: 社会构成 是指 参与人员的构成, 比如: 数量, 角色 等</p>
            

            <ul>
                <li>A body of code that's seen by developers as a single unit</li>
                
                <li>一组代码，开发者将其视为一个整体。</li>

                <li>A group of functionality that business customers see as a single unit</li>
                
                <li>一组功能，商业客户将其视为一个整体。</li>

                <li>An initiative that those with the money see as a single budget</li>
                
                <li>一个提议，拥有资金的人视为一个预算。</li>
            </ul>

            <p>Such a loose definition leads to many potential sizes of an
                application, varying from a few to a few hundred people on the development
                team. (You'll notice I look at size as the amount of people involved,
                which I feel is the most useful way of measuring such things.) The key
                difference between this and enterprise architecture is that there is a
                significant degree of unified purpose around the social
                construction.</p>
            
            <p>这样的宽松定义导致了应用程序可能有多种潜在的大小，开发团队人数从几个到几百个不等。
                （您可能会注意到，我关注涉及的人员数量，我认为这是衡量这类事物最有用的方式。）
                这与企业架构之间的关键区别在于，企业架构围绕社会构成的相同目标是非常显著的。</p>
            
            <p>笔记: 企业的社会构成是显著的，应用的社会构成不够显著，但作为社会构成的原理也是相同的</p>

        </section>

        <section class="card-box">
            <div class="article-card">
                <h3><a href="./bliki/ApplicationBoundary.html">Application Boundary 应用程序边界</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>One of the undecided problems of software development is deciding
                        what the boundaries of a piece of software is. (Is a browser part of
                        an operating system or not?) Many proponents of Service Oriented
                        Architecture believe that applications are going away - thus future
                        enterprise software development will be about assembling services
                        together.</p>
                    
                    <p>软件开发中尚未解决的问题之一是决定一个软件项目的范围。
                        （浏览器是否是操作系统的组成部分？）
                        许多面向服务的架构（Service Oriented Architecture）的拥护者认为应用程序正在消亡 
                        —— 因此未来的企业软件开发将关注于将服务组装在一起。
                        </p>
                        

                    <p>I don't think applications are going away for the same reasons
                        why application boundaries are so hard to draw. Essentially
                        <b>applications are social constructions</b>:
                    
                    <p>我认为应用程序不会消失，原因与应用程序范围难以划定的原因相同。
                        本质上，<b>应用程序是社会构造</b>:
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">11 Sep 2003</p>

                        <p class="more"><a href="./bliki/ApplicationBoundary.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="./tags/team%20organization.html">team
                                    organization</a></span> <span class="tag-link"><a
                                    href="./tags/application%20integration.html">application integration</a></span> <span
                                class="tag-link"><a href="./tags/application%20architecture.html">application
                                    architecture</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./microservices">Microservices Guide</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="./microservices/microservices-sq.png"
                            style="height: 100px; padding-left: 50px"></p>

                    <p class="abstract">The microservice architectural pattern is an approach to developing
                        a single application as a suite of small services, each running in its own
                        process and communicating with lightweight mechanisms, often an HTTP resource
                        API. These services are built around business capabilities and independently
                        deployable by fully automated deployment machinery. There is a bare minimum of
                        centralized management of these services, which may be written in different
                        programming languages and use different data storage technologies. While their
                        advantages have made them very fashionable in the last few years, they come
                        with the costs of increasing distribution, weakened consistency and require
                        maturity in operational management.</p>
                    
                    <p class="abstract">微服务架构模式是一种将单个应用程序开发为一组小型服务的做法，
                        每个服务都在其自己的进程中运行，并通过轻量级机制进行通信，通常是HTTP资源API。
                        这些服务围绕业务能力构建，并且可以通过完全自动化的部署机械独立部署。
                        这些服务几乎没有集中管理，它们可能使用不同的编程语言编写，并使用不同的数据存储技术。
                        尽管在过去几年中它们的优势使它们变得非常流行，
                        但它们也带来了增加分布式特性的成本，削弱了一致性，并且需要成熟的管理运营能力。</p>


                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="more"><a href="./microservices">Read more…</a></p>

                        <p class="type guide">guide</p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/application%20architecture.html">application architecture</a></span>
                            <span class="tag-link"><a href="./tags/web%20services.html">web services</a></span> <span
                                class="tag-link"><a href="./tags/microservices.html">microservices</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/serverless.html">Serverless Architectures 无服务架构</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/serverless/sps.png"></p>

                    <p class="abstract">
                        Serverless architectures are application designs that incorporate third-party “Backend as a
                        Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers
                        on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like
                        single-page applications, such architectures remove much of the need for a traditional always-on
                        server component. Serverless architectures may benefit from significantly reduced operational
                        cost, complexity, and engineering lead time, at a cost of increased reliance on vendor
                        dependencies and comparatively immature supporting services.
                    </p>
                    
                    <p class="abstract">
                        无服务架构是应用程序设计, 包含了第三方“后端即服务”(BaaS)服务，以及/或者包括自定义代码， 使用在“功能即服务”(FaaS)平台上的受管理的 短暂的容器
                        通过使用这些想法，以及相关的一些想法，如单页应用程序，这样的架构移除了对传统始终开启的服务器组件的大部分需求。
                        无服务器架构可能从显著降低运营成本、复杂性和工程领先时间中受益，
                        但代价是增加了对供应商依赖性的增加和相对不成熟的配套服务的依赖。
                    </p>

                    <div class="meta">
                        <p class="credits">by Mike Roberts</p>

                        <p class="date">22 May 2018</p>

                        <p class="more"><a href="./articles/serverless.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="./tags/popular.html">popular</a></span> <span
                                class="tag-link"><a href="./tags/application%20architecture.html">application
                                    architecture</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/micro-frontends.html">Micro Frontends 微前端</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/micro-frontends/card.png"></p>

                    <p class="abstract">
                        Good frontend development is hard. Scaling frontend development so that many
                        teams can work simultaneously on a large and complex product is even harder.
                        In this article we'll describe a recent trend of breaking up frontend
                        monoliths into many smaller, more manageable pieces, and how this
                        architecture can increase the effectiveness and efficiency of teams working
                        on frontend code. As well as talking about the various benefits and costs,
                        we'll cover some of the implementation options that are available, and we'll
                        dive deep into a full example application that demonstrates the technique.
                    </p>
                    
                    <p class="abstract">
                        优秀的前端开发是困难的。
                        可扩展的前端开发更难, 使许多团队能够同时在一个大而复杂的产品上进行前端开发
                        在这篇文章中，我们将描述一个最近趋势，即将前端单体拆分为许多更小、更易于管理的部分，以及这种架构如何提高团队在前端代码上的工作有效性和效率。
                        除了讨论各种利益和成本之外，我们还将介绍一些可用的实施选项，
                        并且我们将深入探讨一个完整的示例应用程序，该应用程序演示了这种技术。
                    </p>
                    

                    <div class="meta">
                        <p class="credits">by Cam Jackson</p>

                        <p class="date">19 Jun 2019</p>

                        <p class="more"><a href="./articles/micro-frontends.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/application%20architecture.html">application architecture</a></span>
                            <span class="tag-link"><a href="./tags/front-end.html">front-end</a></span> <span
                                class="tag-link"><a href="./tags/microservices.html">microservices</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./eaaDev/uiArchs.html">GUI Architectures</a></h3>

                <div class="card-body">In the mid 2000s I was pursuing a couple writing projects that
                    could have turned into books, but haven't yet made it. One was on the
                    architecture of user interfaces. As part of this work, I drafted a
                    description of how GUI architectures evolved, comparing the
                    default approach of Forms and Controls with the the
                    Model-View-Controller (MVC) pattern. MVC is one of the most
                    ill-understood patterns in the software world, understandably so since it was
                    not well documented. So my writing here tries to give a better picture of
                    what MVC really means and how it evolved through Model-View-Presenter and
                    other forms.
                    <div class="meta">
                        <p class="date">18 Jul 2006</p>

                        <p class="more"><a href="./eaaDev/uiArchs.html">Read more…</a></p>

                        <p class="tags"> <span class="tag-link"><a href="./tags/design.html">design</a></span> <span
                                class="tag-link"><a href="./tags/application%20architecture.html">application
                                    architecture</a></span> <span class="tag-link"><a
                                    href="./tags/front-end.html">front-end</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./bliki/PresentationDomainDataLayering.html">Presentation Domain Data Layering 表现层数据分层</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/bliki/images/presentationDomainDataLayering/all_basic.png">
                    </p>

                    <p>One of the most common ways to modularize an information-rich
                        program is to separate it into three broad layers: presentation (UI), domain logic
                        (aka business logic), and data access. So you often see web
                        applications divided into a web layer that knows about handling HTTP
                        requests and rendering HTML, a business logic layer that contains
                        validations and calculations, and a data access layer that
                        sorts out how to manage persistent data in a database or remote
                        services.</p>
                    
                    <p>将信息丰富的程序模块化的最常见方法是
                        将它分为三个广泛的层次：表示层（UI）、领域逻辑（也称为业务逻辑）和数据访问。
                        因此，你经常看到Web应用程序被划分为一个Web层，该层了解处理HTTP请求和渲染HTML，
                        一个业务逻辑层，该层包含验证和计算，
                        以及一个数据访问层，该层负责如何管理数据库或远程服务中的持久数据。</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">26 Aug 2015</p>

                        <p class="more"><a href="./bliki/PresentationDomainDataLayering.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="./tags/team%20organization.html">team
                                    organization</a></span> <span class="tag-link"><a
                                    href="./tags/database.html">database</a></span> <span class="tag-link"><a
                                    href="./tags/encapsulation.html">encapsulation</a></span> <span class="tag-link"><a
                                    href="./tags/application%20architecture.html">application architecture</a></span>
                            <span class="tag-link"><a href="./tags/web%20development.html">web development</a></span>
                        </p>
                    </div>
                </div>
            </div>
        </section>

        <hr class="sep">

        <section class="synopsis ent" id="EnterpriseArchitecture">
            <h2>Enterprise Architecture</h2>

            <p>While application architecture concentrates on the architecture within
                some form of notional application boundary, enterprise architecture looks
                architecture across a large enterprise. Such an organization is usually too
                large to group all its software in any kind of cohesive grouping, thus
                requiring coordination across teams with many codebases, that have developed
                in isolation from each other, with funding and users that operate
                independently of each other.</p>
            
            <p>尽管应用程序架构专注于某种概念性的应用程序边界内的架构，
                但企业架构则关注跨越大型企业的架构。
                这样的组织通常太大，无法将其所有软件分组到任何类型的凝聚性分组中，
                因此需要跨多个代码库、独立发展的团队之间的协调，这些团队在资金和用户方面独立于彼此。</p>

            <p>Much of enterprise architecture is about understanding what is worth the
                costs of central coordination, and what form that coordination should take.
                At one extreme is a central architecture group that must approve all
                architectural decision for every software system in the enterprise. Such
                groups slow down decision making and cannot truly understand the issues
                across such a wide portfolio of systems, leading to poor decision-making. But
                the other extreme is no coordination at all, leading to teams duplicating
                effort, inability for different system to inter-operate, and a lack of
                skills development and cross-learning between teams.</p>
                
            <p>企业架构的很大一部分是关于理解什么值得投入中心协调的成本，以及这种协调应该采取什么形式。
                在一个极端情况下，有一个中心架构团队，必须批准企业中每个软件系统的所有架构决策。
                这样的团队会减慢决策速度，并且无法真正理解如此广泛系统组合中的问题，导致决策质量差。
                但另一个极端是完全没有协调，导致团队重复工作，不同系统之间无法相互操作，以及团队之间缺乏技能发展和跨学科技能。</p>

            <p>Like most people with an agile mindset, I prefer to err on the side of
                decentralization, so will head closer to the rocks of chaos rather than
                suffocating control. But being on that side of the channel still means we
                have to avoid the rocks, and a way to maximize local decision making in a
                way that minimizes the real costs involved.</p>
            
            <p>像大多数具有敏捷心态的人一样，我倾向于倾向于去中心化，
                所以我会更靠近混乱的岩石，而不是令人窒息的控制。
                但站在这条溪流的这边，我们仍然必须避免岩石，
                并且要以最大限度地增加局部决策的方式，同时最小化实际成本。</p>
        </section>

        <section class="card-box ent-arch">
            <div class="article-card">
                <h3><a href="./ieeeSoftware/enterpriseArchitects.pdf">Enterprise Architects Join the Team</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="./img/catalog/ieee-arch-team.png" style="height: 250px"></p>

                    <p class="abstract">Enterprise Architecture groups often get separated from day to day
                        development. This can lead to their knowledge of development work getting
                        out of date and development teams not taking a broad company-wide
                        perspective. Having seen this happen frequently my colleague (ThoughtWorks
                        CTO) Rebecca argues that enterprise architects can be much more effective by
                        joining development teams.</p>
                    
                    <p class="abstract">企业架构小组经常与日常开发分离。
                        这可能导致他们的开发工作知识变得过时，
                        并且开发团队不会采取广泛的公司范围内的视角。
                        我的同事（ThoughtWorks的首席技术官）Rebecca经常看到这种情况发生，
                        她认为企业架构师可以通过加入开发团队来提高他们的效率。</p>

                    <div class="meta">
                        <p class="credits">by Rebecca Parsons</p>

                        <p class="date">Sep 2005</p>

                        <p class="more"><a href="./ieeeSoftware/enterpriseArchitects.pdf">Read more…</a></p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/ieeeSoftware.html">ieeeSoftware</a></span> <span class="tag-link"><a
                                    href="./tags/enterprise%20architecture.html">enterprise architecture</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/ea-in-lean-enterprise.html">The Role of an Enterprise Architect in a Lean
                        Enterprise</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/ea-in-lean-enterprise/card.png">
                    </p>

                    <p class="abstract">
                        When an organization takes on an agile mindset, enterprise architecture
                        doesn't go away, but the role of enterprise architects changes. Enterprise
                        Architects no longer make choices, but help others make the right choice and
                        then radiate that information. Enterprise Architects still need to form a
                        vision, but then need to build bridges between teams to build communities of
                        learning. These will allow teams to explore new approaches and learn from
                        each other, with Enterprise Architects as partners in that growth.
                    </p>
                    
                    <p class="abstract">
                        当一个组织采用敏捷心态时，企业架构并没有消失，但企业架构师的角色发生了变化。
                        企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。
                        企业架构师仍然需要形成一个愿景，但随后需要构建桥梁，以便团队之间建立学习社区。
                        这将使团队能够探索新的方法并相互学习，企业架构师作为这种成长中的合作伙伴。
                    </p>

                    <div class="meta">
                        <p class="credits">by Kevin Hickey</p>

                        <p class="date">30 Nov 2015</p>

                        <p class="more"><a href="./articles/ea-in-lean-enterprise.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="./tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="./tags/enterprise%20architecture.html">enterprise
                                    architecture</a></span> <span class="tag-link"><a
                                    href="./tags/technical%20leadership.html">technical leadership</a></span> <span
                                class="tag-link"><a href="./tags/lean.html">lean</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/products-over-projects.html">Products Over Projects</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p class="abstract">Software projects are a popular way of funding and organizing software
                        development. They organize work into temporary, build-only teams and are funded with specific
                        benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams
                        working
                        on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their
                        end-to-end
                        cycle time, and allows validation of actual benefits by using short-cycle iterations while
                        maintaining
                        the architectural integrity of their software to preserve their long-term effectiveness.</p>
                        
                    
                    <p class="abstract">软件项目是资助和组织软件开发的流行方式。
                        它们将工作组织成临时的、仅用于构建的团队，并且通过业务案例中预测的具体利益来资助。
                        相比之下，产品模式使用持久性的、构思-构建-运行的团队，致力于持续的业务问题。
                        产品模式允许团队快速重新定位，减少他们的端到端周期时间，
                        并通过使用短周期迭代来验证实际利益，同时保持软件架构的完整性，以保持他们的长期有效性。</p>
                        

                    <div class="meta">
                        <p class="credits">by Sriram Narayan</p>

                        <p class="date">20 Feb 2018</p>

                        <p class="more"><a href="./articles/products-over-projects.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/enterprise%20architecture.html">enterprise architecture</a></span> <span
                                class="tag-link"><a href="./tags/team%20organization.html">team organization</a></span>
                        </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/architect-elevator.html">The Architect Elevator — Visiting the upper floors</a>
                </h3>

                <div class="card-body">
                    <p class="card-image"><img src="./articles/architect-elevator/taipei101.jpg"
                            style="height: 250px; padding-left: 50px"></p>

                    <p class="abstract">
                        Many large organizations see their IT engine separated by many floors from the
                        executive penthouse, which also separates business and digital strategy from the vital work
                        of carrying it out. The primary role of an architect is to ride the elevators between
                        the penthouse and engine room, stopping wherever is needed to support these digital
                        efforts: automating software manufacturing, minimizing up-front decision making, and
                        influencing the organization alongside technology evolution.
                    </p>
                    
                    <p class="abstract">
                        许多大型组织看到他们的IT引擎与高管层隔着许多楼层，
                        这也将业务和数字战略与实际执行这些工作的重要工作分离开来。
                        架构师的主要角色是乘坐电梯在顶层公寓和机房之间上下，在需要时随时停车以支持这些数字努力：自动化软件制造，最小化前期决策，并随着技术的发展影响组织。
                    </p>

                    <div class="meta">
                        <p class="credits">by Gregor Hohpe</p>

                        <p class="date">24 May 2017</p>

                        <p class="more"><a href="./articles/architect-elevator.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/enterprise%20architecture.html">enterprise architecture</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="./articles/enterpriseREST.html">Enterprise Integration Using REST</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/articles/enterpriseREST/logical-environments.png"></p>

                    <p class="abstract">
                        Most internal REST APIs are one-off APIs purpose built for a single integration point.
                        In this article, I'll discuss the constraints and flexibility that you have with nonpublic APIs,
                        and lessons learned from doing large scale RESTful integration across multiple teams.
                    </p>
                    
                    <p class="abstract">
                        大多数内部REST API是为单一集成点专门构建的一次性API。
                        在这篇文章中，我将讨论非公共API所具有的限制和灵活性，
                        以及从跨多个团队进行大规模RESTful集成中学到的经验教训。
                    </p>

                    <div class="meta">
                        <p class="credits">by Brandon Byars</p>

                        <p class="date">18 Nov 2013</p>

                        <p class="more"><a href="./articles/enterpriseREST.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a
                                    href="./tags/application%20integration.html">application integration</a></span> <span
                                class="tag-link"><a href="./tags/web%20services.html">web services</a></span> <span
                                class="tag-link"><a href="./tags/enterprise%20architecture.html">enterprise
                                    architecture</a></span> </p>
                    </div>
                </div>
            </div>
        </section>
    </main>


    <!-- 第三部分 -->
    <nav id="bottom-navmenu" style="display: none;">
        <nav class="navmenu">
            <div class="nav-head">
                <div class="search">
                    <!-- SiteSearch Google -->
                    <form method="GET" action="https://www.google.com/search">
                        <input type="hidden" name="ie" value="UTF-8">
                        <input type="hidden" name="oe" value="UTF-8">
                        <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                        <button class="button" type="submit" name="btnG" value=" " title="Search">
                            <input type="hidden" name="domains" value="martinfowler.com">
                            <input type="hidden" name="sitesearch" value="">
                            <input type="hidden" name="sitesearch" value="martinfowler.com">

                        </button>
                    </form>
                </div>

                <div class="closediv">
                    <span class="close" title="close"></span>
                </div>
            </div>

            <div class="nav-body">
                <div class="topics">
                    <h2>Topics</h2>

                    <p><a href="./architecture">Architecture</a></p>

                    <p><a href="https://refactoring.com">Refactoring</a></p>

                    <p><a href="./agile.html">Agile</a></p>

                    <p><a href="./delivery.html">Delivery</a></p>

                    <p><a href="./microservices">Microservices</a></p>

                    <p><a href="./data">Data</a></p>

                    <p><a href="./testing">Testing</a></p>

                    <p><a href="./dsl.html">DSL</a></p>
                </div>

                <div class="about">
                    <h2>about me</h2>

                    <p><a href="./aboutMe.html">About</a></p>

                    <p><a href="./books">Books</a></p>

                    <p><a href="./faq.html">FAQ</a></p>
                </div>

                <div class="content">
                    <h2>content</h2>

                    <p><a href="./videos.html">Videos</a></p>

                    <p><a href="./tags">Content Index</a></p>

                    <p><a href="./articles/eurogames">Board Games</a></p>

                    <p><a href="./photos">Photography</a></p>
                </div>

                <div class="tw">
                    <h2>ThoughtWorks</h2>

                    <p><a href="https://thoughtworks.com/insights">Insights</a></p>

                    <p><a href="https://thoughtworks.com/careers">Careers</a></p>

                    <p><a href="https://thoughtworks.com/products">Products</a></p>
                </div>

                <div class="feeds">
                    <h2>follow</h2>

                    <p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

                    <p><a href="./feed.atom">RSS</a></p>
                </div>
            </div>
        </nav>
    </nav>
    <!-- 脚部, 脚部导航 -->
    <footer id="page-footer">
        <div class="tw-logo">
            <a href="http://www.thoughtworks.com">
                <img src="https://martinfowler.com/tw-white-300.png">
            </a>
        </div>
        <div class="menu-button">
            <div class="icon-bars navmenu-button"></div>
        </div>
        <div class="copyright">
            <p>© Martin Fowler | <a href="http://www.thoughtworks.com/privacy-policy">Privacy Policy</a> | <a
                    href="./aboutMe.html#disclosures">Disclosures</a></p>
        </div>
    </footer>


    <script src="./jquery-3.5.1.min.js" type="text/javascript"></script>
    <script src="./mfcom.js" type="text/javascript"></script>
    <script type="text/javascript">encloseWhenSmall('.article-card', 'h3');</script>
</body>


</html>